![[Amazon FSx for NetApp ONTAP] ファイル名にUTF-8の4バイト文字を含むファイルを作成できるように設定してみた](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] ファイル名にUTF-8の4バイト文字を含むファイルを作成できるように設定してみた
このファイルだけ追加ができないな
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)を使っていて「このファイルだけ追加ができないな」と思ったことはありますか? もしかしたら、そのファイルの名前にUTF-8の4バイト文字が含まれているかもしれません。
FSx for ONTAPのボリュームのデフォルトの言語設定はC.UTF-8です。C.UTF-8が扱える文字は最大3バイトまでで、4バイト文字はサポートしていません。
そのため、?(つちよし = U+20BB7)や?(ほっけ = U+29E3D)などの一部漢字や?(= U+1F604)、?(= U+1F4B0)といった絵文字などUnicodeのU+10000以上の文字を含むファイル名をつけようとするとエラーになります。
どれがU+10000以上かはUnicode 15.0 Character Code Chartsの以下リストが分かりやすいかと思います。
絵文字は専用のリストがあるので、以下が見やすいです。
ONTAPではONTAP 9.5以降でUTF-8の4バイト文字であるutf8mb4をサポートしています。
FSx for ONTAPでもutf8mb4を使用できるか確認してみました。
いきなりまとめ
- ボリュームのデフォルト言語設定は
C.UTF-8 C.UTF-8が扱える文字は3バイトまでutf8mb4に設定することでUTF-8の4バイト文字も扱えるようになる2022/12/13時点で、既存ボリュームの言語設定をC.UTF-8からutf8mb4に変更することはできない- 既存ボリュームの言語設定を
C.UTF-8からutf8mb4に変更することはできる - ただし、テクニカルサポートから指示がされた場合のみ変更すること
- データの整合性に懸念がある場合は、新規に
utf8mb4のボリュームを作成して、ファイルを移行すること - 既存ボリュームの言語設定を
utf8mb4からC.UTF-8に変更することはできない
- 既存ボリュームの言語設定を
- デフォルトの言語設定の変更はSVM毎に行う
- クライアントが
utf8mb4をサポートできない場合を除き、基本的にはutf8mb4を設定するのがオススメ- SVMを作成したらまずはボリュームの言語設定を
utf8mb4に変更しよう
- SVMを作成したらまずはボリュームの言語設定を
検証環境
検証環境は以下の通りです。
AD DCからはSMBで、NFSクライアントからはNFSで接続し、言語設定がutf8mb4のボリューム上にUTF-8の4バイト文字を含むファイルを作成します。
AD DCについては以下記事の検証で使用したものを流用します。
検証で使用するFSx for ONTAPファイルシステム、SVM、ボリュームは以下の通りです。
# FSx for ONTAPファイルシステム
$ aws fsx describe-file-systems
{
"FileSystems": [
{
"OwnerId": "<AWSアカウントID>",
"CreationTime": "2022-12-13T00:49:14.983000+00:00",
"FileSystemId": "fs-0ca3d1e244ed3089b",
"FileSystemType": "ONTAP",
"Lifecycle": "AVAILABLE",
"StorageCapacity": 1024,
"StorageType": "SSD",
"VpcId": "vpc-08b84da1f793ed513",
"SubnetIds": [
"subnet-08dc789896a48a3b4"
],
"NetworkInterfaceIds": [
"eni-0616d61f100e6f99c",
"eni-0dc8b1120b0ca55b6"
],
"KmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/365ae19c-8016-4963-9afd-05f703509254",
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:file-system/fs-0ca3d1e244ed3089b",
"Tags": [
{
"Key": "aws:cloudformation:stack-name",
"Value": "FsxnStack"
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "FSxforONTAPfilesystem"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:us-east-1:<AWSアカウントID>:stack/FsxnStack/78cdb890-5423-11ed-81fb-0eac30df53d1"
},
{
"Key": "Name",
"Value": "fsx-for-ontap-file-system"
}
],
"OntapConfiguration": {
"AutomaticBackupRetentionDays": 7,
"DailyAutomaticBackupStartTime": "16:00",
"DeploymentType": "SINGLE_AZ_1",
"Endpoints": {
"Intercluster": {
"DNSName": "intercluster.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.123",
"10.0.1.113"
]
},
"Management": {
"DNSName": "management.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.125"
]
}
},
"DiskIopsConfiguration": {
"Mode": "AUTOMATIC",
"Iops": 3072
},
"PreferredSubnetId": "subnet-08dc789896a48a3b4",
"ThroughputCapacity": 128,
"WeeklyMaintenanceStartTime": "6:17:00"
}
}
]
}
# SVM
$ aws fsx describe-storage-virtual-machines
{
"StorageVirtualMachines": [
{
"ActiveDirectoryConfiguration": {
"NetBiosName": "SVM",
"SelfManagedActiveDirectoryConfiguration": {
"DomainName": "CORP.NON-97.NET",
"OrganizationalUnitDistinguishedName": "OU=FSxForONTAP,DC=corp,DC=non-97,DC=net",
"UserName": "FSxServiceAccount",
"DnsIps": [
"10.0.1.10"
]
}
},
"CreationTime": "2022-12-13T00:54:26.341000+00:00",
"Endpoints": {
"Iscsi": {
"DNSName": "iscsi.svm-07a067590e6c8fb2b.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.72",
"10.0.1.100"
]
},
"Management": {
"DNSName": "svm-07a067590e6c8fb2b.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.87"
]
},
"Nfs": {
"DNSName": "svm-07a067590e6c8fb2b.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.87"
]
},
"Smb": {
"DNSName": "SVM.CORP.NON-97.NET",
"IpAddresses": [
"10.0.1.87"
]
}
},
"FileSystemId": "fs-0ca3d1e244ed3089b",
"Lifecycle": "CREATED",
"Name": "SVM",
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-0ca3d1e244ed3089b/svm-07a067590e6c8fb2b",
"StorageVirtualMachineId": "svm-07a067590e6c8fb2b",
"UUID": "bd40adaf-7a80-11ed-b4b5-e1824c95e39e"
}
]
}
# ボリューム
$ aws fsx describe-volumes
{
"Volumes": [
{
"CreationTime": "2022-12-13T00:55:02+00:00",
"FileSystemId": "fs-0ca3d1e244ed3089b",
"Lifecycle": "CREATED",
"Name": "SVM_root",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/",
"SecurityStyle": "UNIX",
"SizeInMegabytes": 1024,
"StorageEfficiencyEnabled": false,
"StorageVirtualMachineId": "svm-07a067590e6c8fb2b",
"StorageVirtualMachineRoot": true,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "c662d28a-7a80-11ed-b4b5-e1824c95e39e",
"OntapVolumeType": "RW",
"SnapshotPolicy": "default",
"CopyTagsToBackups": false
},
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0ca3d1e244ed3089b/fsvol-0babe1baadc159e7b",
"VolumeId": "fsvol-0babe1baadc159e7b",
"VolumeType": "ONTAP"
},
{
"CreationTime": "2022-12-13T01:00:13.077000+00:00",
"FileSystemId": "fs-0ca3d1e244ed3089b",
"Lifecycle": "CREATED",
"Name": "vol1",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/vol1",
"SecurityStyle": "UNIX",
"SizeInMegabytes": 1024,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-07a067590e6c8fb2b",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "8ebed0d8-7a81-11ed-b4b5-e1824c95e39e",
"OntapVolumeType": "RW",
"SnapshotPolicy": "default",
"CopyTagsToBackups": false
},
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0ca3d1e244ed3089b/fsvol-0129505e31eccf03e",
"VolumeId": "fsvol-0129505e31eccf03e",
"VolumeType": "ONTAP"
}
]
}
言語がC.UTF-8のボリューム上ではUTF-8の4バイト文字を含むファイルを作成できないことを確認
まず、言語がC.UTF-8のボリューム上ではUTF-8の4バイト文字を含むファイルを作成できないことを確認します。
ボリュームのでデフォルトの言語(language)はC.UTF-8です。
::> volume show -fields language vserver volume language ------- -------- -------- SVM SVM_root C.UTF-8 SVM vol1 C.UTF-8 2 entries were displayed.
試しに/vol1上に?を食べたいです.txtというファイルを作成します。
AD DCでルートボリュームのファイル共有c$をZドライブにマウントします。
# ルートボリュームのファイル共有 c$ をZドライブにマウント > net use Z: \\SVM.CORP.NON-97.NET\c$ The command completed successfully. # Zドライブにマウントできていることを確認 > Get-PSDrive Name Used (GB) Free (GB) Provider Root CurrentLocation ---- --------- --------- -------- ---- --------------- Alias Alias C 15.89 14.11 FileSystem C:\ Users\Administrator Cert Certificate \ Env Environment Function Function HKCU Registry HKEY_CURRENT_USER HKLM Registry HKEY_LOCAL_MACHINE Variable Variable WSMan WSMan Z 0.00 0.95 FileSystem \\SVM.CORP.NON-97.NET\c$
エクスプローラー上でZ:\vol1配下に?を食べたいです.txtを作成しようとすると、The filename, directory name, or volume label syntax is incorrect.と怒られてしまいました。
なお、内容が?を食べたいですでファイル名がホッケを食べたいです.txtというファイルは作成できました。
PowerShellでもホッケを食べたいです_utf-16-le.txtの内容は表示できました。(PowerShell 5.x系はUTF-16なので、UTF-16 LEのファイルも作成しました)
> cat Z:\vol1\ホッケを食べたいです_utf-16-le.txt ?を食べたいです
次にNFSクライアントから/vol1をマウントして、ホッケを食べたいです.txtを表示できることを確認します。
# マウントポイント作成 $ sudo mkdir /mnt/fsxn # /vol1 をマウント $ sudo mount -t nfs svm-07a067590e6c8fb2b.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/ # マウントされたことを確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-07a067590e6c8fb2b.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com:/vol1 nfs4 973M 384K 973M 1% /mnt/fsxn # /vol1 配下のファイル確認 $ ls -l /mnt/fsxn/ total 0 -rwxr-xr-x 1 root daemon 25 Dec 13 02:40 ホッケを食べたいです.txt -rwxr-xr-x 1 root daemon 20 Dec 13 02:42 ホッケを食べたいです_utf-16-le.txt # ホッケを食べたいです.txt を表示できることを確認 $ cat /mnt/fsxn/ホッケを食べたいです.txt ?を食べたいです
?を食べたいですという欲望を表示できました。
それでは、?を食べたいです.txtというファイルを作成してみます。
# ?を食べたいです.txt の作成 $ echo ?を食べたいです | sudo tee /mnt/fsxn/?を食べたいです.txt > /dev/null # ?を食べたいです.txt が作成されたか確認 $ ls -la /mnt/fsxn/ total 4 drwxr-xr-x 2 root root 4096 Dec 13 03:09 . drwxr-xr-x 3 root root 18 Dec 13 02:49 .. -rwxr-xr-x 1 root daemon 25 Dec 13 02:40 ホッケを食べたいです.txt -rwxr-xr-x 1 root daemon 20 Dec 13 02:42 ホッケを食べたいです_utf-16-le.txt
特に拒否はされませんでしたが、ファイルが作成されていないようです。
しかし、AD DCのZドライブからvol1配下を確認すると~1というテキストファイルが作成されていました。こちらのファイルを開くと?を食べたいですと記載されています。
~1という謎のファイルが作成されるのは困りますね。
ボリュームの言語を utf8mb4 に変更する
それではボリュームの言語を utf8mb4 に変更します。
UTF-8からutf8mb4への変換はできるようです。
複数のボリューム言語を使用することはできません。また、ボリュームの作成後にボリュームの言語を変更することはできません ただし、 UTF-8 から utf8mb4 は除きます
それではやってみます。
# 設定できる言語一覧を確認
::> volume modify -volume vol1 -language
C da de
en en_US es
fi fr he
it ja ja_JP.PCK
ko no nl
pt sv zh
zh.GBK zh_TW zh_TW.BIG5
C.UTF-8 ar ar.UTF-8
cs cs.UTF-8 da.UTF-8
de.UTF-8 en.UTF-8 en_US.UTF-8
es.UTF-8 fi.UTF-8 fr.UTF-8
he.UTF-8 hr hr.UTF-8
hu hu.UTF-8 it.UTF-8
ja.UTF-8 ja_v1 ja_v1.UTF-8
ja_JP.PCK.UTF-8 ja_JP.932 ja_JP.932.UTF-8
ja_JP.PCK_v2 ja_JP.PCK_v2.UTF-8 ko.UTF-8
no.UTF-8 nl.UTF-8 pl
pl.UTF-8 pt.UTF-8 ro
ro.UTF-8 ru ru.UTF-8
sk sk.UTF-8 sl
sl.UTF-8 sv.UTF-8 tr
tr.UTF-8 zh.UTF-8 zh.GBK.UTF-8
zh_TW.UTF-8 zh_TW.BIG5.UTF-8 utf8mb4
# vol1 の言語を C.UTF-8 から utf8mb4 に変換
::> volume modify -volume vol1 -language utf8mb4
Error: command failed: Changing the language of a volume is not supported. Contact technical support for assistance.
# advanced 権限で再チャレンジ
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
::*> volume modify -volume vol1 -language utf8mb4
Error: command failed: Changing the language of a volume is not supported. Contact technical support for assistance.
はい、できませんでした。
以下のKBやコマンドリファレンスでは*.UTF-8からutf8mb4の変更はできると記載されています。
ONTAP 9.7P1 では、ボリュームの言語を *.UTF-8 から utf8mb4 に変更できます。
ONTAP 9 は utf8mb4 をサポートしますか？ - NetApp
[-language ] - Language
Use this parameter to change the volume language from *.UTF-8 to utf8mb4. To change the language of a volume, contact technical support.
ただし、既存のボリュームをutf8mb4に変更することはできないと記載しているドキュメントもあります。
既存のボリュームを utf8mb4 をサポートするように変更することはできません。 utf8mb4 対応の新しいボリュームを作成し、クライアントベースのコピーツールを使用してデータを移行する必要があります。
SVM は utf8mb4 をサポートするように更新できますが、既存のボリュームの言語コードは元の設定のままです。
注記
現在のところ、 4 バイトの UTF-8 文字を含む LUN 名はサポートされていません。
どちらが正しいのか分かりませんが、事実としてFSx for ONTAPではできませんでした。どうしても既存ボリュームの言語をutf8mb4に変更したい場合はエラー文にContact technical support for assistanceとあるので、サポートに問い合わせましょう。
2023/3/8 追記ここから
ONTAP 9.7P1以降では権限レベルをdiagnosticにすると、言語をutf8mb4に変更できるとNetAppのKBで紹介されていました。
Beginning in ONTAP 9.7P1, a volume's language can be changed to utf8mb4 via diagnostic commands
FSx for ONTAPのバージョンを確認すると、ONTAP 9.11.1P5でした。
::> version NetApp Release 9.11.1P5: Sat Dec 10 23:54:17 UTC 2022
そのため、既存ボリュームの言語設定をC.UTF-8からutf8mb4に変更することはできそうですね。
実際にやってみましょう。
検証環境を作り直したので、ファイル共有の作成から行います。SVMとボリュームはマネジメントコンソールから作成しました。
# 現在のボリュームの言語設定の確認
::> volume show -vserver svm_2 -volume vol1 -fields language
vserver volume language
------- ------ --------
svm_2 vol1 C.UTF-8
# CIFSサーバーの確認
::> cifs show -vserver svm_2
Vserver: svm_2
CIFS Server NetBIOS Name: CIFS-SERVER
NetBIOS Domain/Workgroup Name: CORP
Fully Qualified Domain Name: CORP.NON-97.NET
Organizational Unit: OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
Default Site Used by LIFs Without Site Membership:
Workgroup Name: -
Authentication Style: domain
CIFS Server Administrative Status: up
CIFS Server Description:
List of NetBIOS Aliases: -
# ファイル共有の作成
::> cifs share create -vserver svm_2 -share-name utf8mb4-test -path /vol1
# 作成したファイル共有の確認
::> cifs share show -vserver svm_2 -share-name utf8mb4-test
Vserver: svm_2
Share: utf8mb4-test
CIFS Server NetBIOS Name: CIFS-SERVER
Path: /vol1
Share Properties: oplocks
browsable
changenotify
show-previous-versions
Symlink Properties: symlinks
File Mode Creation Mask: -
Directory Mode Creation Mask: -
Share Comment: -
Share ACL: Everyone / Full Control
File Attribute Cache Lifetime: -
Volume Name: vol1
Offline Files: manual
Vscan File-Operations Profile: standard
Maximum Tree Connections on Share: 4294967295
UNIX Group for File Create: -
作成したファイル共有をZドライブにマウントします。
> net use Z: \\CIFS-SERVER\utf8mb4-test The command completed successfully. > Get-PSDrive -PSProvider FileSystem Name Used (GB) Free (GB) Provider Root CurrentLocation ---- --------- --------- -------- ---- --------------- C 15.81 14.19 FileSystem C:\ Users\Administrator Z 0.00 0.95 FileSystem \\CIFS-SERVER\utf8mb4-test
エクスプローラー上でファイル共有配下に?を食べたいです.txtを作成しようとすると、The filename, directory name, or volume label syntax is incorrect.と怒られることを確認します。
代わりにホッケを食べたいです.txtというファイルは作成できることを確認します。
この状態でボリュームの言語設定をC.UTF-8からutf8mb4に変更します。
# 権限レベルを diagnostic に変更
::> set diagnostic
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
# ボリュームの言語設定を C.UTF-8 から utf8mb4 に変更
::*> volume modify -vserver svm_2 -volume vol1 -language utf8mb4
Warning: You should only change the volume language from "*.UTF-8" to "utf8mb4" when you are directed to do so by
technical support.
Do you want to continue? {y|n}: y
Volume modify successful on volume vol1 of Vserver svm_2.
# ボリュームの言語設定が utf8mb4 に変更されたことを確認
::*> volume show -vserver svm_2 -volume vol1 -fields language
vserver volume language
------- ------ --------
svm_2 vol1 utf8mb4
ボリュームの言語設定がutf8mb4に変更されましたね。なお、変更しようとすると「テクニカルサポートから指示がされた場合のみ変更するように」と警告が表示されました。
また、NetAppのKBの書きっぷりを見ると、既存ボリュームの言語設定の変更はデータの整合性に影響を与えそうに見えます。そういった意味でもボリューム作成後に言語設定を変更するのは推奨されていなさそうですね。
- 変換が行われないため、この変更が破壊的であるとは知られていません。
- データの整合性に懸念がある場合は、新しい utf8mb4 ボリュームを作成し、ファイルベースのコピーを使用してデータを移行してください。
ボリュームの言語設定をutf8mb4に変更後は?を食べたいです.txtと4バイト文字を含むファイル名でファイルを作成することができました。
また、既存のホッケを食べたいです.txtというファイルを開くこともできました。
最後にボリュームの言語設定をutf8mb4からC.UTF-8に変更できるか試してみます。
::*> volume modify -vserver svm_2 -volume vol1 -language C.UTF-8
Error: command failed: Modification not permitted. Changing the language of a volume is only supported if the current
language is "*.UTF-8" and the new language is "utf8mb4".
権限レベルがdiagnosticであっても怒られました。ボリュームの言語設定をutf8mb4からC.UTF-8することは変更できないようです。
2023/3/8 追記ここまで
言語が utf8mb4 のボリュームの作成
FSx for ONTAPでは既存ボリュームの言語変更ができないようなので、新規にutf8mb4のボリュームを作成します。
作成するボリュームのジャンクションパスは/vol2です。
# utf8mb4 のボリュームを作成 ::> volume create -volume vol2 -aggregate aggr1 -size 1G -security-style unix -type RW -junction-path /vol2 -language utf8mb4 -vserver SVM [Job 40] Job succeeded: Successful # utf8mb4 のボリュームが作成されたことを確認 ::> volume show -fields language vserver volume language ------- -------- -------- SVM SVM_root C.UTF-8 SVM vol1 C.UTF-8 SVM vol2 utf8mb4 3 entries were displayed.
作成できました。
言語が utf8mb4 のボリューム上でUTF-8の4バイト文字を含むファイルを作成できることを確認
それでは言語が utf8mb4 のボリューム上でUTF-8の4バイト文字を含むファイルを作成できることを確認します。
エクスプローラー上でZ:\vol2配下に?を食べたいです.txtを作成します。
あっさり作成できました。文字化けもしていないです。
PowerShellからも?を食べたいです.txtを確認できました。
> ls Z:\vol2\
Directory: Z:\vol2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/12/2022 6:46 PM 25 ?を食べたいです.txt
NFSクライアントからも確認してみます。
# アンマウント $ sudo umount /mnt/fsxn/ # /vol2 をマウント $ sudo mount -t nfs svm-07a067590e6c8fb2b.fs-0ca3d1e244ed3089b.fsx.us-east-1.amazonaws.com:/vol2 /mnt/fsxn/ # ?を食べたいです.txt があることを確認 $ ls -la /mnt/fsxn/ total 4 -rwxr-xr-x 1 root daemon 25 Dec 13 04:46 ?を食べたいです.txt drwxr-xr-x 2 root root 4096 Dec 13 04:46 . drwxr-xr-x 3 root root 18 Dec 13 02:49 .. # ?を食べたいです.txt の内容を表示 $ cat /mnt/fsxn/?を食べたいです.txt ?を食べたいです
NFSからも認識できましたね。
次に?.txtという絵文字を含むテキストファイルを作成してみます。
# ?.txt の作成 $ echo ? | sudo tee /mnt/fsxn/?.txt > /dev/null # ?.txt が作成されたことを確認 $ ls -l /mnt/fsxn/ total 0 -rw-r--r-- 1 root root 5 Dec 13 04:56 ?.txt -rwxr-xr-x 1 root daemon 25 Dec 13 04:46 ?を食べたいです.txt # ?.txt の表示 $ cat /mnt/fsxn/?.txt ?
作成できましたね。
AD DCのエクスプローラーからも?.txtを確認できました。
ボリュームのデフォルトの言語を utf8mb4 に設定する
ボリュームの言語をutf8mb4に設定するすることで、ファイル名にUTF-8の4バイト文字が含まれるファイルが作成できることを確認しました。
しかし、都度ボリュームを作成する際にONTAP CLIで-language utf8mb4と指定するのも大変です。加えてAWSマネジメントコンソールやAWS CLIからボリュームを作成する際は言語設定を指定することはできません。
そのような場合はSVMでボリュームのデフォルトの言語を変更することで対応できます。
ボリュームのデフォルトの言語を変更する場合は、vserver modifyで-languageを指定します。
ここで設定した言語が、以降作成されるボリュームのデフォルトの言語になります。
実際に試してみましょう。デフォルトの言語をC.UTF-8からutf8mb4に変更します。
# 現在の言語設定を確認 ::> vserver show -fields language vserver language ------- -------- SVM C.UTF-8 # utf8mb4 に変更 ::> vserver modify -vserver SVM -language utf8mb4 # utf8mb4 に変更されたことを確認 ::> vserver show -fields language vserver language ------- -------- SVM utf8mb4
それでは、この状態でマネジメントコンソールからvol3というボリュームを作成します。
作成されたボリュームの言語設定を確認します。
::> volume show -fields language vserver volume language ------- -------- -------- SVM SVM_root C.UTF-8 SVM vol1 C.UTF-8 SVM vol2 utf8mb4 SVM vol3 utf8mb4 4 entries were displayed.
utf8mb4でボリュームが作成されましたね。
なお、utf8mb4からC.UTF-8`の変換は怒られました。
::> volume modify -volume vol2 -language C.UTF-8 Error: command failed: Changing the language of a volume is not supported. Contact technical support for assistance.
ボリュームの言語設定を utf8mb4 にしよう
Amazon FSx for NetApp ONTAPでファイル名がUTF-8の4バイト文字に対応するようにボリュームの言語設定をしてみました。
NetAppのドキュメントを確認するとボリュームの言語はutf8mb4が推奨されていました。
Support for utf8mb4 volume language
As previously mentioned, special characters might exceed the supported three bytes UTF-8 encoding that is natively supported. ONTAP then uses the bagofbits functionality to allow these characters to work.
This method for storing inode information is not ideal, so starting in ONTAP 9.5, utf8mb4 volume language support was added. When a volume uses this language, special characters that are four bytes in size will be stored properly and not in bagofbits.
Volume language is used to convert names sent by NFSv3 clients to Unicode, and to convert on-disk Unicode names to the encoding expected by NFSv3 clients. In legacy situations in which NFS hosts are configured to use non-UTF-8 encodings, you will want to use the corresponding volume language. Use of UTF-8 has become almost universal these days, so the volume language is likely to be UTF-8.
NFSv4 requires use of UTF-8, so there is no need to use non-UTF-8 encoding for NFSv4 hosts. Similarly, CIFS uses Unicode natively, so it will work with any volume language. However, use of utf8mb4 is recommended because files with Unicode names above the basic plane are not converted properly on non-utf8mb4 volumes.
Volume language can only be set on a volume at creation by using the -language option. You cannot covert a volume’s language. To use files with a new volume language, create the volume and migrate the files by using a utility such as the XCP Migration Tool.
Best Practice 4: UTF-8 or utf8mb4?
If you’re running ONTAP 9.5 or later, it is best to use the utf8mb4 volume language to help prevent issues with file name translation unless clients are unable to support the language.
NFS best practice and implementation guide | TR-4067
(以下機械翻訳)
utf8mb4ボリューム言語への対応
前述のように、特殊文字は、ネイティブでサポートされている3バイトのUTF-8エンコードを超える場合があります。その場合、ONTAPはbagofbits機能を使用して、これらの文字が動作するようにしています。
inode情報を格納するこの方法は理想的ではないため、ONTAP 9.5から、utf8mb4ボリューム言語サポートが追加されました。ボリュームがこの言語を使用する場合、サイズが4バイトの特殊文字は、bagofbitsではなく、適切に保存されます。
ボリューム言語は、NFSv3クライアントから送信された名前をUnicodeに変換し、ディスク上のUnicode名をNFSv3クライアントが期待するエンコーディングに変換するために使用されます。NFSホストがUTF-8以外のエンコードを使用するように構成されているレガシーな状況では、対応するボリューム言語を使用することをお勧めします。UTF-8の使用は最近ほぼ一般的になってきているため、ボリューム言語はUTF-8になる可能性が高いです。
NFSv4ではUTF-8を使用する必要があるため、NFSv4ホストで非UTF-8エンコードを使用する必要はありません。同様に、CIFSはネイティブにUnicodeを使用するため、どのようなボリューム言語でも動作します。ただし、基本プレーン以上のUnicode名を持つファイルは、utf8mb4以外のボリュームでは適切に変換されないため、utf8mb4の使用をお勧めします。
ボリューム言語は、作成時に-languageオプションを使用してボリュームにのみ設定することができます。ボリュームの言語を隠蔽することはできません。新しいボリューム言語でファイルを使用するには、ボリュームを作成し、XCP Migration Toolなどのユーティリティを使用してファイルを移行してください。
ベストプラクティス4：UTF-8かutf8mb4か？
ONTAP 9.5以降を実行している場合、クライアントがその言語をサポートできない場合を除き、ファイル名変換の問題を防ぐためにutf8mb4ボリューム言語を使用することが最善です。
クライアントがutf8mb4をサポートできない場合を除き、基本的にはutf8mb4を設定するのがお勧めされているようです。
他ドキュメントでも以下のような記載がありました。
複数の文字セット ( エンコード ) が必要な場合 ( 英語 / アラビア語など ) は、 utf8mb4 文字セット ( エンコード用 ) を使用することをお勧めします。
複数の文字セットの例として、英語 / アラビア語が挙げられているのであれば、英語 / 日本語の環境もutf8mb4を使う方が良さそうです。
ということで、SVMを作成した際は、まずデフォルトのボリュームの言語設定を変更しましょう。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] Amazon Bedrock Agents のメモリ保持期間が最大 30 日から 365 日に変更されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e3065182082062711612153bbdcf1d96/c04359de689df2f56eb066576ab63fb5/amazon-bedrock)
![[アップデート]Amazon Connect のキューとルーティングプロファイルを管理コンソールから削除できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-a14da8621c55bd17addadcead8e0e00f/c928a36480d9593938e8d8f65ba92537/amazon-connect)
![[アップデート] Amazon QuickSight のデータセットでユニークキーが設定出来るようになったので挙動を検証してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
